As various forms of distributed computing, such as cloud computing, have come to dominate the computing landscape, security has become a bottleneck issue that currently prevents the complete migration of various capabilities and systems associated with sensitive data, such as financial data, to cloud-based computing environments, and/or other distributive computing models. This is because many owners and operators of data centers that provide access to data and other resources are extremely hesitant to allow their data and resources to be accessed, processed, and/or otherwise used, by virtual assets, such as virtual machine and server instances in the cloud.
One mechanism historically used to control access to the data and other resources is the use/application of secrets such as, but not limited to, passwords, passphrases, encryption keys, and digital certificates, to control and authenticate entities desiring to access various types of data and resources.
There is little doubt that the use of secrets is an effective method for ensuring that data and other resources are only accessible by an authorized entity. However, the management, selective application, and maintenance of secrets is a complicated and time consuming task that currently is performed in a largely manual manner with significant opportunities for the introduction of error and the risk of malicious actors gaining access to secrets and the data they protect.
For instance, many secrets, such as passwords and encryption keys, must not only be generated and applied according to the type of data they are intended to protect, but the data representing secrets themselves must be also be protected. In addition, in many cases, once the secrets have been deployed and applied to the data to be protected, the secrets must then be re-applied, rotated, or changed, on a periodic basis, with the period between rotation and/or change being dependent on the type of data being protected. That is to say, the policy determining what secrets are selected, and how those secrets are maintained and managed, is dependent on the type of data being protected. This, in and of itself, can be a complicated process when multiple types of data, and multiple types of secrets, from multiple sources, are involved. However, in addition, in many cases, the data is processed in a pipeline manner with one or more secrets being used to protect the data at various stages in the pipeline. Consequently, keeping track of the secrets applied to given data, and where the data protected by those secrets is located at any given time, can be an extremely complicated process. This is particularly true in light of the fact that, as noted, this process is currently performed on a largely manual basis.
For instance, as a specific illustrative example, currently, the application and management of encryption keys typically involves human beings first determining what level of encryption is required for a specific type of data to be protected, e.g., a determination must be made as to the policy with respect to levels of encryption and encryption keys associated with specific types of data. Then, once it is determined what level of encryption needs to be applied to the data in accordance with one or more policies, the encryption keys must be manually obtained and largely manually applied to the data to be protected.
In this specific illustrative example, a human operator must then determine and track when the encryption keys are due to be rotated in accordance with the policy associated with the specific data being protected. Then, new encryption keys must be generated and associated with the old encryption keys which are used to decrypt the data and then re-encrypt the data using the new encryption keys. In one embodiment, once it is determined that all the data protected with the old encryption keys has been re-encrypted with the new encryption keys, then the old encryption keys must be manually retired and the process is complete until the next required rotation of encryption keys in accordance with the policy associated with the specific type of data.
As can be seen from the discussion above, using the current manual methods of managing, applying, and maintaining secrets, even on a single type of data, is a resource intensive process subject to significant human error. In addition, due to the complications associated with managing, applying, and maintaining secrets using current methods, policies associated with secrets are typically rigidly applied in as simplistic a manner as possible in order to reduce the opportunity of introducing human error. Consequently, secrets management policies currently lack the flexibly to adapt to new threats and new situations/environments.
In addition, using the current manual methods of managing, applying, and maintaining secrets, the extensive use of human input, and often multiple human beings, in the management, application, and maintenance of secrets, means that there is significant opportunity for malicious actors to take part in the process. Consequently, the very data intended to be protected by the rather extensive manual secrets management, application, and maintenance methods currently used is placed at risk by the process of protecting the data itself.
In addition, when the secrets to be applied are stored and/or accessed from a computing environment, such as a data center, that is remote and distinct from the computing environment, such as a cloud, where the virtual assets needing the secrets exist, and where the secrets are typically used/applied, there can be significant latencies associated with the management, application, and maintenance, of secrets. Again, this is particularly problematic given that, currently, secrets management, application, and maintenance is largely a manual process.
What is needed is a method and system to manage, apply, and maintain, secrets data in accordance with one or more secrets management policies that are automatically determined based on the specific type of data to be protected, that is highly automated in application, that minimizes latencies, and that can operate in multiple environments, without compromising the secrets, the resources accessed using the secrets, and/or any data or objects associated with the secrets.